DevOps

2023-03-27 07:43| 来源: 网络整理| 查看: 265

总第013篇撰文丨王咚咚出品丨王咚咚编辑部

往期相关推荐

发刊词 | 警惕知识的诅咒

DevOps | 从“瀑布”到“敏捷”

DevOps | 敏捷实践：Scrum结合DDD

关于本话题的说明

截至目前，“DevOps”话题的系列推送已经来到了第三篇，但我们仍没有提及DevOps的具体概念。一些朋友可能会有疑问，这符合知识讲解的逻辑么？如果你已经对DevOps有所了解的话，可能曾有过这种体会，就是当我们去给别人介绍DevOps的时候，往往绞尽脑汁也难以想出一个妥帖、严谨的定义。我们可以很轻易地说出DevOps的目的（例如“促进研发与运维的沟通协作”），也能够找出很多定语来形容它（例如“高效的"），但落到最后一个名词时，也就是“DevOps是什么”的时候，就不知道该怎么说了。

DevOps是一种指导思想？

DevOps是一种企业文化？

DevOps是一组自动化的运维工具？

似乎每个都有一定道理，但又不完全准确。实际上，DevOps是一系列过程、方法、工具的统称，正如我们前文提到过的“筐型理论”：“DevOps是个筐，啥都可以往里装”。DevOps这种“筐型理论”的性质与常人的认知规律是相违背的。如果我们把它当作一种理论来讲解的话，即开篇就讲解它的来源和定义，初学者可能反而会一头雾水。我们不如反其道而行之，先把各类实践方法讲清楚，最后再给它们总结归纳到DevOps的范围内（其实DevOps的方法可能比它本身的历史还要久远），我认为这样的论述方法会更加地合理而有效。在公众号的首篇推送里（《警惕知识的诅咒》），我们就讨论过关于“表达与理解”的话题，大家可以点击上方“往期推荐”中的链接进行浏览。

持续集成

对于“持续集成(Continuous Integration，简称CI)”，我们可以把这个词拆分来看。

“集成”的意义在于，将各模块开发中的代码“组装”起来，构建出可运行的程序，以供后续的质量审查与产品验证。由于软件架构的多样性，“组装”的内容可能是单体应用的模块代码，也可能是分布式系统的多个独立微服务，等等。

为什么要“持续”呢？我们在前文（请参考《从“瀑布”到“敏捷”》）已经讲解过瀑布模型的相关弊端，一言以蔽之，越是容易发现问题的环节，我们就越应该提前做、频繁做、持续做。持续集成要求我们为了保证迭代的质量，要更高频地集成。持续集成的频率通常是一天多次，有时甚至是每小时都会发生多次。“持续集成”这个概念，最早来自于极限编程（Extreme Programming，简称XP）方法。XP同Scrum类似，也是敏捷的具体实践方案。我们在前文中论述过的“敏捷”与“加班”的矛盾关系，关于此问题的相关思考最早就出自于XP。

问题来了，随着系统规模的复杂化，“集成”会变得相对麻烦且耗时，这与我们高频次的“持续”要求会产生矛盾。这就引出了持续集成的核心要求，那就是集成的“自动化”，而自动化集成的实现主要依托于“流水线”。

流水线

流水线（Pipeline，或称为管线）这个词，即便在软件工程领域，也是比较常见的。它表示将重复性的工作定义为流程，流程内部划分为多个阶段（stage），每个阶段也可能包含多个步骤，每个阶段或步骤由单独的“生产者”（也就是机器或工人）负责实施。“流水线”将工作流程的编排标准化，流程环节中的每一个生产者只需要专注于自身的业务环节，提高了资源利用效率。

卓别林《摩登时代》

接下来，我们需要进一步确定两个问题：

（1）流水线都包含哪些步骤？

我们可以这样简单描述一下持续集成流水线：当需要进行代码集成的时候（例如某特性分支提交了merge request），最新的代码会进入这条流水线，然后自动地进行构建、测试、部署等环节。流水线结束后，研发人员就可以直接对最新版本的程序进行后续的评估和调试了。如果流水线中某环节出现问题，系统也会第一时间通知研发团队。

上图为Jenkins的流水线示意图。值得注意的是，在图右侧的管道出口指向了“Production”，也就是说这个流水线在完成集成的基础上，还自动完成了生产环境的交付部署，这个过程称之为持续交付（Continuous delivery，简称CD）。持续交付并不是本文讨论的重点，但究其逻辑与方法，与持续集成是一致的。Jenkins提供了通过声明式代码编写流水线的方法，如下文所示，Jenkinsfile中代码1表示了流水线需要的测试环境，代码2到7表示了各个阶段以及步骤，这些都是可以自定义的，以配合各类型项目的实际需要。

pipeline {

agent any 1 stages { stage('Build') { 2 steps { // 3 } } stage('Test') { 4 steps { // 5 } } stage('Deploy') { 6 steps { // 7 } } }

}

（2）流水线需要哪些“组件”？

Jenkins作为一个CI&CD软件工具，主要功能在于对流水线上的“生产环节”进行编排，至于每个环节如何进行，则几乎要全部依赖于外部工具（也就是前面说的流水线上的各个生产者）。Jenkins的一大成功之处，就是打造了一个庞大的插件生态社区，里面提供了几乎全部我们熟知的相关系统的接入方法，用于持续拓展Jenkins的功能。

简单列举一下流水线可能需要加入的外部工具：

代码仓库：GitLab

代码质量检查：SonarQube

构建打包：Maven

自动化部署：Ansible

容器镜像仓库：Harbor

制品仓库：Nexus

自动化测试：TestNG、JMeter、Selenium

环境管理：Kubernetes

结果通知：电子邮件、钉钉

... ...

最佳实践之路

持续集成需要实现团队内部高效的流程效果，同时兼顾简洁直观的使用体验。其实大家已经看到了，由于持续集成内部关联的组件及方案的多样化，加上实施各类方案本身的复杂性限制，所以团队找寻最佳实践的道路，注定不会轻松容易。

另一方面，为了建立“云原生”的平台环境，Jenkins以及相关的外部工具都需要部署在Kubernetes上，流水线也需要把构建好的程序运行在Kubernetes上，这要求我们对持续集成实践有着更深入的规划与思考。

在后续的推送中，我们将继续探讨这个问题。

立足小城，侧耳听风

2021年，陪你聊聊云原生、交互设计、技术管理

【本文地址】

公司简介

联系我们